Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a data stream. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. IPsec can be used to protect data flows between a pair of hosts (e.g. computer users or servers), between a pair of security gateways (e.g. routers or firewalls), or between a security gateway and a host. IPsec is a dual mode, end-to-end, security scheme operating at the Internet Layer of the Internet Protocol Suite or OSI model Layer 3. Some other Internet security systems in widespread use, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers of these models. Hence, IPsec can be used for protecting any application traffic across the Internet. Applications need not be specifically designed to use IPsec. The use of TLS/SSL, on the other hand, must typically be incorporated into the design of applications.
In the field of Internet Protocol (IP) networks, access to a wireless communication unit's IP network (termed remote private IP network) is not currently possible using second generation (2G) wireless communication equipment, for example a global system for mobile (GSM) communication unit or 2 G communication unit capable of general packet radio system (GPRS) communications sometimes referred to as 2.5G capability).
Evolved Packet Core (EPC) is the IP-based core network defined by 3GPP in Release-8 for use by long-term evolution (LTE) and other access technologies. The goal of EPC is to provide a simplified all-IP core network architecture to efficiently provide access to various services, such as the ones provided in IMS (IP Multimedia Subsystem). EPC consists essentially of a Mobility Management Entity (MME) and access agnostic Gateways for routing of user datagrams.
However, currently, there is no known GPRS/EPC solution that exists to enable a wireless communication unit, such as a 3GPP user equipment (UE), to access its remote private IP network. In particular, no GPRS/EPC solution exists for a non-roaming UE to remotely access its private IP network, for example its home base station (sometimes referred to as a home Node B (HNB) or home evolved Node B (H(e)NB) in 3GPP parlance). Furthermore, no GPRS/EPC solution exists for a roaming UE to remotely access its private IP network, when the UE roams to other public land mobile networks (PLMNs). This is especially the case where the H(e)NB that serves as a Gateway does not belong to the same home (H-)PLMN of the UE.
The only known mechanism for providing access to the remote private IP network is for a wireless communication unit to access its remote private IP network over the Internet, using for example a secure tunneling mechanism, such as Encapsulating Security Payload (ESP) of the IPSec protocol suite, and using a Virtual Private Network (VPN). ESP tunnel mode encapsulates an IP data packet with ESP protocol, an IP header and an ESP authentication trailer. The ESP protocol also defines an authenticated format that provides data authentication and integrity, with data privacy. ESP takes the data carried by IP, such as a transmission control protocol (TCP) packet, and encrypts the TCP packet using an encryption algorithm and cryptographic key. The output is ciphertext that is difficult to decode without knowing the key. The receiving IPSec ESP entity uses an associated decryption algorithm and the same key to extract the original data. When IPSec tunnel mode is used, IPSec encrypts the IP header and the payload, whereas transport mode only encrypts the IP payload. Tunnel mode provides the protection of an entire IP packet by treating it as an authentication header (AH) or ESP payload. With tunnel mode, an entire IP packet is encapsulated with an AH or ESP header together with an additional IP header. The IP addresses of the outer IP header are the tunnel endpoints, and the IP addresses of the encapsulated IP header are the ultimate source and destination addresses. IPSec tunnel mode is useful for protecting traffic between different networks, when traffic must pass through an intermediate, un-trusted network. Tunnel mode is primarily used for interoperability with gateways, or end-systems that do not support L2TP/IPSec or PPTP connections.
It is known that a number of problems exist in providing access to the remote private IP
network using the aforementioned secure tunneling mechanism. First, the secure tunneling mechanism requires the two ends (i.e. both the UE and the Home Gateway) to have public IP addresses, or at least private IP addresses that will require a number of notational address translations (NATs) when communications pass between the UE and Home Gateway. In addition, the secure tunneling mechanism requires the UE and Home Gateway to own and maintain IPSec credentials that can be used in order to establish security association between the UE and its remote private IP network. Even though maintenance of IPSec security credentials is a well-known procedure in the management of large scale IP networks, it is not used in a domestic, small scale IP network for domestic users. Furthermore, IPsec capability is not a feature that is supported in a majority of present-day UEs.
It is also known that 3GPP-style quality of service (QoS) management (for example as
defined in TS 23.401[1] and TS 23.060[5]) cannot be performed in a virtual private network (VPN) that is using an IPSec tunneling mechanism over the Internet. Hence, if a UE is attempting to access a type of traffic that requires special handling, the UE will only be provided with a “best effort” QoS service, since the PLMN in which the UE is attached is unable to differentiate between different types of IP traffic provided from the remote private IP network.
Hence, the current solution of using IPSec over the public Internet in order to establish VPN and access the remote private IP network is a suboptimal procedure that requires a significant administrative load for the average user. In addition, especially for enterprise corporate networks, using IPSec over the public Internet in order to establish VPN and access the remote private IP network requires the UE to support special software.
Referring now to FIG. 1, a known architecture 100 (as shown in TS 29.061[3] of 3GPP
rel.99) that could be used to establish VPN connectivity to remote private IP managed networks is illustrated. This architecture is based on the principle that the mobile network's home PLMN(HPLMN) Gateway (for example a P-GW or GGSN) connects with the external IP network. The architecture 100 includes a packet domain network 105 attached to a GGSN 115 in a remote private IP network 110. The remote private IP network 110 also includes a DHCP entity 125. The remote private IP network 110 is operably coupled to an Operator-specific IP network 135 via a Gi reference interface 130. A domain name server (DNS) 125 is also coupled to the Operator-specific IP network 135. The Operator-specific IP network 135 is coupled to an external IP network 145 via a firewall or proxy function 140.
Referring now to FIG. 2, a message sequence chart 200 illustrates an accessing of a remote packet data network (PDN) belonging to an external Intranet/ISP using a known mechanism and the GPRS/EPC architecture 100 of FIG. 1. A static or a dynamic IPv4 address belonging to the Intranet/ISP addressing space is allocated to a UE at IP-CAN session establishment. If requested by the UE at IP-CAN session establishment, the P-GW may retrieve the Protocol Configuration Options or IPv4 configuration parameters from a locally provisioned database in P-GW and/or from some external server (i.e. DHCPv4, RADIUS AAA, Diameter AAA) belonging to the Intranet/ISP. The communication between the Packet Domain and the Intranet/ISP may be performed over any network, even an insecure network, e.g. the Internet. In case of an insecure connection between
the P-GW and the Intranet/ISP, there may be a specific security protocol in between. This security protocol is defined by mutual agreement between PLMN operator and Intranet/ISP administrator.
The methods of allocating IP address to the UE are specified in 3GPP TS 23.060[5], 3GPP TS 23.401[1] and 3GPP TS 23.402[4]. The allocated IPv4 address is used for packet forwarding within the P-GW and for packet forwarding on the Intranet/ISP. The message sequence chart 200 details the communications between terminal equipment (TE) 202, an associated mobile terminal (MT) 204, a serving general packet radio system (GPRS) support node (SGSN) 206, a gateway GPRS support node 208 and an internet service provider (ISP) or intranet communication network 210 involved in allocating the IPv4 address to the UE. The TE 202 and associated MT 204 transfer at least one or more of the following:
(i) AT commands 212, including an access point name (APN),
(ii) LCP negotiation commands 214, including MRU commands and authentication protection,
(iii) authentication commands 216, including CHAP, PAP commands,
(iv) PCP configuration requirements 218, including IP address information, header
compression, etc.
The MT 204 stores authentication parameters received from the TE 202 in step 220.
Furthermore, upon receiving a packet control protocol (PCP) configuration requirements message 218 from the TE 202, the MT 204 initiates an activate packet data packet (PDP) context requirements message 222 to the SGSN 206. The PDP context requirements message 222 comprises APN, quality of service (QoS), PDP-type, NSAPI, protocol configuration options. In response thereto, the SGSN 206 sends, in step 224, a create PDP context requirements message to the GGSN 208. The create PDP context requirements message comprises APN, QoS, PDP-type, NSAPI, protocol configuration options.
There are two known options for allocating a static or a dynamic IPv4 address belonging to the Intranet/ISP addressing space to a UE at IP-CAN session establishment. A first option 230 uses a RADIUS access request by the GGSN 208 to the ISP/intranet 210 following receipt of a create PDP context requirements message, as shown in step 232, and an acceptance, as shown in step 234, returned from the ISP/intranet 210 to the GGSN 208 with authentication and configuration information. A second option 240 also uses a RADIUS access request by the GGSN 208 to the ISP/intranet 210 following receipt of a create PDP context requirements message, as shown in step 232, and an acceptance, as shown in step 234, returned from the ISP/intranet 210 to the GGSN 208 with authentication and configuration information. However, the second option further comprises a DHCP-DISCOVER message being sent by the GGSN 208 to the ISP/intranet 210 in step 242 and a DHCP-OFFER message being returned in response to the discover message, as shown in step 244. Thereafter, the second option further comprises a DHCPREQUEST message being sent by the GGSN 208 to the ISP/intranet 210 in step 246 and a DHCPACK (acknowledge) message being returned in response to the request message, as shown in step 248.
The GGSN 208 then sends, in step 250, a create PDP context response message to SGSN 206. The create PDP context response message comprises protocol configuration options and a cause. In response thereto, the SGSN 206 sends an Activate PDP context Acc message to the MT 204, in step 252, where the Activate PDP context Acc message comprises protocol configuration options and the cause. The MT 204 then sends a PCP Configuration-Ack message to the TE 202 in step 254 with the IP-address and header compression to be used.
Thus, as a part of the IP-CAN session establishment, the P-GW may request user authentication from an external AAA server (i.e. RADIUS, Diameter) belonging to the Intranet/ISP. Furthermore, the GGSN 208 stores the IP-address and composes an NCP-IPCP Configure-Ack packet.
In addition to the above problems with known access mechanisms, the existing requirements in TS 22.220 of 3GPP, for Managed Remote Access limit remote access to the home based network, limit access to only those UEs that are members of the Closed Subscriber Group (CSG). Although restricting remote access to CSG members potentially provides the H(e)NB Hosting Party with a simple level of control over those UEs that are able to remotely connect to the remote private IP network, it is believed that this potentially represents a lost revenue opportunity for the Operator to which the H(e)NB is affiliated. For example, a mechanism is already required to enable access restriction on a per-subscriber basis, even if the subscriber is a CSG member. The present requirements for remote access to a home based network in Release 9 of TS 22.220 are as follows:
(i) The H(e)NB may support remote access for a CSG member to the home based network from a UE via a PLMN in order to provide access to IP capable devices connected to the home based network.
(ii). It shall be possible to restrict the access to the home based network on per-subscriber basis (e.g. some subscribers may have managed access to their home network and others may not).